Note: "suntar" does NOT mean computers by Sun Microsystems, it's "Speranza's un-tar" since it extracts tar archives (i.e. un-tars their contents) created on any UNIX machine (including Sun, but also IBM, HP and others). The application icon is only a graphical joke which does not want to represent the Sun logo.
What's suntar ?
Really, suntar is becoming two things in one. It's a MacBinary, BinHex, uuencode and PackIt extractor, and it's one of the fastest extractors you can find, and one of the few which may convert more files in one operation (only with drag&drop, by now). That may be enough to let you wish use it.
But its original purpose was to communicate, acting as a bridge between a UNIX workstation and the Mac if a few, minimal hardware requirements are met: that is, a physical medium must be connected to both machines. That's usually easy with floppy disks but almost any SCSI device may be used instead.
Finally, handling devices requires some bookkeeping: this may be seen as a third personality.
We believe that programs like suntar should disappear in a future world where any computer will exchange data naturally with any computer, but by now computers and their data are often totally incompatible and suntar is useful.
To understand what it does, it's useful to tell how the whole thing started: we had just got the new, wonderful Macintosh LC, but one of us was a student and at the University he had to work on a Sun SPARCstation 1: is it possible to communicate data between the two machines, without using a network or a modem ? The SPARCstation has a 3.5" disk drive, why shouldn't it be possible to save a file on a floppy disk at the University and read it back on our Mac, or vice-versa ? That would be useful both for working (typing a C program at home before compiling it on the Sun) and downloading Mac files from all those ftp-able places in the world.
The Apple SuperDrive can read and write disks in the two IBM formats, 720K and 1440K with MFM encoding: for simplicity and compatibility, all 3.5" drives manufacturers have adopted this de-facto standard, hence there should be no difficulty to read a disk written on any UNIX workstation on a Macintosh with a SuperDrive. Unfortunately, for a while Apple did not adhere to that standard, the 400K and 800K drives used exclusively an Apple proprietary physical encoding called GCR which can't be read or written on a non-Apple disk drive.
But the SuperDrive is compatible, and it's present on all recent Mac models: it's missing only in the older models (128K, 512K, Plus, the SEs built before September 89 and not upgraded with a FDHD kit, and the original Macintosh II without other letters in its name and not upgraded).
Furthermore, with a few exceptions the ancient UNIX hasn't learned yet about floppy disk drives: they must be set up to emulate a tape drive unit, handled by the tar utility. That's good for us, since tar uses a simple, standard format: no allocation tables, inodes and other complex, nonportable data structures, files are stored sequentially preceded by a simple header containing their name and a few informations; for directories there is only the header and contained files are stored separately, using the partial path name from the directory you specified.
So, we wrote suntar, a program which runs on a Macintosh and reads and writes a disk in the physical IBM formats containing data in the logical tar format; thinking that it could be useful to many students having the same problem, we added more features, made it easier to use and released it in the public domain.
Usually, we launch suntar and let it perform extractions in background: almost all files arrive with their proper icon and are double-clickable. It's easy to use an application which may recognize file formats without requiring that you tell it which "filter" must be used for each file !
Really, there are three different floppy disk formats you may use on an UNIX workstation in order to exchange data with a Mac:
1) the Macintosh format: we' ve read on magazines about commercial programs which, running on UNIX workstations, should read and write disks in Macintosh format. NeXTStep release 3 includes that capability too, and in the future it might become commonplace.
2) the MS-DOS format: the public domain package "mtools" (or other utilities) can read and write in the MS-DOS format under UNIX, and Apple File Exchange (or PC Exchange or Access PC) can then move the data to your Mac. Inconveniences of such approach are: to move files bigger than a disk is possible but annoying (you must split them); you have no support for Macintosh specific file formats (for example, AFE can translate a MS-DOS ASCII text to a Mac ASCII text, but you must disable such conversion on UNIX files and convert later, or convert twice UNIX->MS-DOS and MS-DOS->Mac); lastly, the portability of UNIX programs is a myth, you get a public domain package in source code but you need the help of an experienced programmer to have it compiled and running.
3) the UNIX formats, that is tar and bar formats. Suntar can read and write such archives, and performs all the most useful file conversions while doing it.
Under UNIX, tar may be used for three purposes:
1) to perform regular back-ups on tape, to be stored and hopefully never used; or to archive rarely used files off-line, on a medium which is cheaper and more capable than a hard disk: that's where the name tar (Tape ARchiver) originally came from.
2) to put together several files into a single file, which may be easier to manage, expecially if you wish to compact it (both the old pack utility and the new compress generate one compressed file per input file).
3) it's the simplest way, and sometimes the only way, to create a physical medium which can be used to distribute programs and data to other computer users.
Suntar was conceived to be mainly a communication program, role 3, allowing Macintosh users to exchange data with UNIX users. It can be used for backups, role 1, but it can't compete with applications written as backuppers. And it may perform role 2 just as well as its two competitors (tar 3.0 and StuffIt Deluxe).
What you need
To exchange data is a difficult art: if you want to fully exploit suntar you should have some basic notions about Mac files: data and resource forks, the MacBinary format (a common way to store a Mac file in an UNIX-style file without losing informations) and so on.
Furthermore, you should know that in text files UNIX separates lines by a Line Feed character while the Mac uses a Carriage Return (MS-DOS uses a CR followed by a LF, just to be incompatible with both).
If your purpose is to download files from ftp-able public domain archives, you should have a bunch of public domain programs to convert file formats:
• .bin files (and all non-ASCII formats) are MacBinary files, directly converted by suntar; you should not need any of the many small utilities performing the conversion, such as BinHex 5.0 (which is a totally different program from BinHex 4.0)
• .hqx files may be converted (usually yielding a .sit or .pit) by suntar itself, by BinHex 4.0 or StuffIt, Compact Pro, Downline or many small utilities. Only a few of these programs (e.g. the DA BinHqx) can decode files splitted in several parts, and suntar can't: if you get a set of parts, you may use United or Unity (or any text editor which accepts very large files) to put all parts together (without any extra text: suntar skips lines such as '----- end of part 1' only if they are before any BinHex data)
• .pit files were created by PackIt, but StuffIt and Downline too support them, and there is a freeware Unpit (which may create them too). Starting from version 1.2, suntar too can extract them by the "Open file" command
• .sit files are almost a standard, recognized by several compression programs on the Mac: their originator (StuffIt 1.5.1) or Compact Pro, Disk Doubler and Downline. However, StuffIt has now evolved to a commercial version, StuffIt Deluxe, with new, incompatible compression methods. StuffIt Deluxe 3.0 and the shareware StuffIt Lite 3.0 have more new methods and StuffIt Expander is the only freeware which may decode all of them
• .cpt files were generated by Compact Pro (once called Compactor); the extract-only versions (cptExpand and Extractor) are freeware. StuffIt Expander too is able to expand cpt files
• .sea files were created by Compact Pro (or other compression programs), but they self-extract themselves when you double-click them
• .gif files are a non-Mac graphical format, supported by many Mac applications and DAs: suntar assigns them the correct type so that graphics programs may recognize them more easily.
If you exchange UNIX files instead of Mac files, you'll need MacCompress which is compatible with the UNIX utility compress (.Z files), or maybe you should use StuffIt Deluxe 3. You might need unshar (to extract .shar files). Suntar, Uutool and other utilities are compatible with uuencode/uudecode.
Finally, DeskZap 1.32 is always handy to change file type and creator, set the bundle bit (some programs come with an icon which is not shown by the Finder because the author has forgotten to set the bundle bit: in that case, you should also clear the "inited" bit to force the Finder to examine that file again) and perform simple file format conversions (DeskZap 2.0 is more powerful but we don't like its new user interface), and the desk accessory System Errors may tell you the meaning of error codes which suntar prints when something is wrong.
Instructions, UNIX side
You must know the device name of the floppy disk: it's "/dev/rfd0" on a Sun 3, SPARCstation or IBM RISC/6000 (which autosense the density), on Sun 386i it's /dev/rfd0 or /dev/rfdl0 according to the density (1440 or 720k), on other machines it might be /dev/rdsk, /dev/rfp, /dev/rflp, and other characters may be optionally appended meaning the currently used density. That initial 'r' is another attribute (raw), /dev/fd0 is the same device but it's accessed with more software overhead. UNIX should tell you the right name when you type "man fdformat" or "man -k disk", otherwise you may ask to your system administrator, or try to explore the /dev directory (devices usually need no special privilege, and all UNIX commands including cat may access them).
Things are more difficult on a NeXTstation: disk devices require root privileges, and if you simply insert a disk, the system tries to mount it (requiring the proper format, incompatible with tar and even with the format of disks mounted by SPARCstations): that's the simplest way to format a disk (don't use a barium-ferrite disk, which is formatted at 2.88K, if you want to read it on a Mac). To create or read a tar archive, you must launch tar, wait for a dialog which asks for the disk, and now insert it. Under NeXT OS 2.0 and 2.1 the device name was /dev/rfd0h for the internal drive and /dev/rsd1h for an external SCSI drive: BEWARE that /dev/rsd0h is the hard disk, and since you must do that with root privileges a mistyped character may cause the destruction of essential informations, so that you won't be able to boot from the hard disk! ! You should try to read from the device (e.g. by "cat /dev/rfd0h") and be sure that's accessing the floppy disk, before trying to write. Under later versions the device is /dev/rfd0b (the digit may be 0 to 7 and is not a drive number, it's dynamically assigned to disks when they are mounted hence if the NeXT asks for a specific disk that number is already assigned and you should try with another one). Finally, you must eject the disk by typing "disk -e -f /dev/rfd0b". (Thanks to Maurizio De Cecco for part of informations about the NeXT).
You may use disks formatted on the UNIX workstation, on an IBM PS/2 or on the Mac, either under suntar itself or Apple File Exchange or the Finder (1440K only).
Beware: MS-DOS and System 7 have a feature that allows you to use disks having bad sectors, by marking them in the allocation table. A tar disk has no allocation table, any bad sector will be used for data if the archive is long enough to reach that sector. Hence, if you have doubts about the quality of your disks you should initialize them under System 6 or suntar, where initialization fails if there are any bad sectors. Suntar 2.0 alerts you if a disk contains sectors marked bad by System 7 or MS-DOS; the UNIX command fdformat does not verify the disk.
On the SPARCstation, the typical operations are performed as follows.
Formatting (it requires no parameters):
fdformat
(on a Silicon Graphics formatting is performed by fx -x then answering:
fx: "device-name" = (dksc) fd
fx: ctrl# = (0) 0
fx: drive# = (1) 3
which floppy type... 3.5
Then choose f(ormat) option).
Write one or more files or directories:
tar cvf /dev/rfd0 filenames
(use the proper name in place of rfd0, and write the list of files and directories in place of "filenames" )
Append:
tar rvf /dev/rfd0 filenames
List:
tar tvf /dev/rfd0
Extract:
tar xvf /dev/rfd0
Copy a .tar file (shorter then the disk) to a disk:
cat filename.tar >/dev/rfd0
Refer to the manual of your system for differences and for other options, or use "man -k disk" for the online help, if it's installed. Obviously, there are many ways to avoid typing those easy-to-forget parameters and any old UNIX user will tell you about them.
The original tar utility can't create an archive longer than a single disk, maybe that was a reasonable limit on tapes but it's not on floppy disks, we happened to download more than 10 MegaBytes of public domain files at one time (or a single file of more than 4 Mbytes) and to manually distribute files among the disks, without exceeding the 1440K limit on each, is really tedious; to split files bigger than 1440K is even more tedious.
Using multi-volume archives is almost a necessity. Any multi-volume program allows an archive to span any number of disks, when a file does not fit in a disk it writes as much data as fits and continues writing the remaining data onto another disk. The splitted files will be recombined when extracting. There are at least three different multi-volume formats (two different extensions of tar and a new program), and all these three formats are fully supported by suntar.
The non-tar program is bar, which might be part of the set of utilities which came with your UNIX (on the SPARCstation it's so). Bar generates archives in a format similar to the tar format, but data fields are placed in a different order, hence the two formats are incompatible. To run bar, simply replace tar by bar in previous examples. Really, bar was badly designed (if a data field happens to be written in a wrong way one should correct the problem, not let the extraction routine ignore that field), and the documentation of its format is full of errors, but according to our experience suntar succeeds to read bar archives without problems.
The POSIX committee has devised a multivolume format, which requires no special parameters to be used, and the tar bundled with AIX for the IBM RISC/6000 follows it. But remember that only the first disk has an header in a fixed place, hence POSIX tar is the only format which obliges you to always insert all the disks in the right order (you should always place a label on the disks with the archive name and disk number, since those informations are not stored inside). Single volume archives generated by POSIX tar (or GNU tar, without the V option) are fully compatible with any version of tar, the difference arises only for archives composed of more than one disk.
Really, I've seen an utility called "vol" which solves the problem of POSIX tar: it exploits the pipes of UNIX in order to add its own volume headers to archives, while tar believes that the device has an infinite length, so any single-volume tar is OK: unfortunately the documentation of vol states that it's part of QNX (a UNIX-like OS) and is not available to other UNIX users, furthermore the format of vol is far from being perfect: I wrote a clone of vol but did not test it, and anyway I did not improve it, a thing which is a necessity. Does anybody want to continue the job ? When a "standard" version of vol will exist, suntar should support it.
Really, POSIX also states that tar and cpio should be merged into a single program, "pax": GNU cpio follows that rule by supporting the tar format (including long names).
Then there is the GNU tar. GNU is an association which freely distributes a set of UNIX utilities compatible with the original ones, in source code: you may get them by anonymous ftp at prep.ai.mit.edu. The GNU version of tar has a few extra options, by specifying M it allows multi-volume archives (that is, type cvfM, rvfM, tvfM, xvfM as parameters); an extra parameter V may be used to assign a label and sequence number to disks. GNU tar does not eject the disks when they are full, hence if the drive hasn't an eject button you must have a shell prompt to issue the eject command. When GNU tar is waiting, you may type ? to get help and ! to get a sub-shell, but if you are annoyed of that you may edit the source of tar so that the function "new_volume" in buffer.c looks like this:
...
else for(;;) {
{ /*addition by Sauro Speranza, 24 oct 1991 and 2 apr 1992 */
int len = strlen(ar_file);
while(ar_file[len-1] != '/' && len > 0) len --; /* strrchr is not always available */
if( !strncmp(&ar_file[len],"rfd",3) || !strncmp(&ar_file[len],"fd",2) ){ /* on the
SPARCstation or RISC/6000, anyway the strings must be the letters in
the device name, the numbers are the string lengths*/
if(ar_file[0] == '/') /* /dev/device */
system("eject");
else { /* host:/dev/device */
char cmd[300];
register char *p = ar_file;
register char *d;
strcpy(cmd,"rsh ");
d=cmd+strlen(cmd);
while( *p && *p != ':' )
*d++ = *p++;
*d = '\0';
if( *p==':' ){
strcat(cmd," eject");
system(cmd);
} else
system("eject");
}
}
} /* end of addition */
fprintf(msg_file,"\007Prepare volume #%d and hit return: ",volno);
...
If you want GNU tar and your tar does not come from GNU (if it does, "tar +version" will print a copyright notice), remember to get the help of an experienced programmer, the source code was written to be portable among several machines (even MS-DOS) but you must taylor some #define's to your system and maybe find where some .h files are; and if your C compiler follows the ANSI standard, disable all the new features: portability of source code for UNIX systems is not perfect, it's difficult to do better than that.
Finally, a new source of incompatibilities arised when people realized that the 99 characters limit for the pathname is really too small, now that UNIX names are no more restricted to 14 characters. So POSIX extended the limit to 256 characters, and GNU tar 1.11 to infinite; unfortunately, the two extensions are totally different and we had to modify suntar in order to accept both (but no more than 255 characters, a limit imposed by the way the Macintosh handles strings).
Instructions: Macintosh side
If you are using System 7 and are satisfied by short descriptions of the commands, turn on balloon help; otherwise, read here.
The usual way to begin to work is by inserting a disk: suntar realizes that it's neither a Mac nor a MS-DOS disk and "opens" it for itself. Otherwise, you may select a command (e.g. List) and suntar will ask you to insert a disk, inconditionally opening it as a tar/bar archive. Or you may open the device and then insert the disk.
The first command in the File menu is "Get file info", it may be used to get informations about any file, but it's more useful for files which suntar can open.
Then there is the usual Open, but its use is not usual: it performs some operations which are not essential for suntar but may be useful. You may open a tar or bar archive which is stored in a Macintosh file on a Macintosh volume, or convert files in one of the following formats: MacBinary, BinHex 4.0, ASCII (UNIX or MS-DOS), uuencode and PackIt (even compressed PackIt archives, but not encrypted ones). Suntar automatically recognizes the file format, and that should be good in most cases, but you may change that by a click (unless you've used the drag&drop feature of System 7, so avoiding the dialog).
You may open files by drag&drop, and the behaviour is sometimes different from Open: the destination folder is selected only once and a non-converted file may be copied.
Open device allows you to open a device driver or a SCSI device, optionally specifying a sector where List and Extract should find a tar archive. See the separate file for more informations.
New archive and encode… well, obviously they do the opposite of Open, creating encoded files.
The Eject command may be used when you no more need the disk, but most commands eject the disk when finished. The usual command-shift-1 and command-shift-2 still eject the disk, but suntar might not realize that the disk is no more there: use Eject or its shortcut command-W instead.
Drive list prints some informations about the devices connected to your Mac: you should examine them carefully before trying to use "Open device".
Copy disk archive to file copies all data found on a disk to a Mac file in the tar or bar format; for multi-volume archives, the extra volume headers on disks other than the first one are skipped, so you get a single-volume archive, but no other data conversion is performed.
List prints the list of the files in the tar or bar archive.
"Extract and convert" is the most useful command and the most frequently used. It reads files from the archive and saves them on the Macintosh. However, Macintosh files are different from UNIX files: they are composed of two parts (the data and resource forks) and their attributes are essential (you can't execute an application if its type is not 'APPL', nor extract a StuffIt archive if it's not 'SIT!'); even pure text files are different, using CR rather than LF (see above). To make things easy, suntar recognizes the most common file formats and automatically converts them to the Macintosh form. That includes pure text files and the two formats used by public domain archives, MacBinary (in three variants) and BinHex (.hqx files); in most cases, you get exactly what you want without having to worry about which conversions must be done. When you don't get what you want you may use the options (Preferences menu) to tell suntar what you want.
"Extract selected files" is like Extract, but allows you to choose which file must be extracted from a scrollable list. A "Find" button allows you to select names containing a given string (for example, if you want to extract all .c and .h files, just use Find twice with those strings).
A note for POSIX tar users (e.g. AIX users): usually suntar allows you to insert any disk of the archive, but that's impossible with the POSIX format. Hence, to extract selected files from the second disk you must insert the first disk, click on the Extract button when no file is selected, then insert the second disk. You must have set the "tar version" option to POSIX, otherwise suntar will not ask for the second disk.
Initialize is like the Initialize command in the Finder, but disks which do not support 1440 Kbytes (have no hole...) are formatted at 720K, a format more suitable to exchange data with UNIX machines; if the relative option is set they are initialized in a way that is completely Finder compatible.
Pause and Abort are what you expect, but you'll be surprised to find them in a menu, in most programs they are missing or are buttons. Well, suntar allows you to pull down menus even when it's working, even when it's performing very low level operations, directly talking to device drivers. That can be very useful, and working in background saves time, but it may be dangerous: as any UNIX application, suntar knows only a drive number, not a disk name: if you eject the tar disk from outside suntar (or you use command shift-1, or the Finder ejects it with its usual change disk dialog or the Eject button in the standard file dialog) and insert a Macintosh disk, suntar might not notice the difference, and if you do that while suntar was writing and the second disk contains the only copy of your most precious data... Well, suntar 2.0 tries to avoid that by comparing sector 0 of the disk currently in the drive with a stored copy of what it should be: for the sake of speed that operation is performed at some critical points, not always, so to be safe you should pause suntar before ejecting its disk: when it's in foreground suntar accepts a disk insertion in the open drive and reopens that disk (or exits from a pause) only if sector 0 matches.
In the Write menu, the two Create commands allow you to start a new archive, overwriting anything was previously on the disk (in Mac style, you may get a few warnings before loosing any data; in order to reduce unintentional data loss, suntar writes any volume header only after you choose the first file to be written). A checkbox allows you to examine the disk (accepting it even if it's write protected) and have an opportunity to eject it before any data is written to it, that's useful for disks following the first one when clicking on "Cancel" to abort the current command is not harmless.
Append is similar but preserves the current contents of the tar/bar archive, adding new files after the existing ones (POSIX tar users must insert all the disks of multi-volume archives, GNU tar and bar users must insert only the last one).
Anyhow, when you are in write mode you select commands in the Write menu and the familiar standard file dialog appears: the Write button allows you to select whole folders, it's equivalent to Open for single files, the Write selected files button transfers the file list into a dialog which allows multiple selections and has a Find button. Choose End of write (or Eject or Abort or Quit) when you have finished.
Files can be written in three different formats: MacBinary saves all the data of a Mac file (using the MacBinary II format, which can be read also by programs which know only about the original MacBinary), ASCII saves the data fork only converting any CR to LF, Data fork only must be used for files already in UNIX format. Mixed write DF/MB tries to choose automatically the correct format (ASCII for text files, MacBinary if there is a resource fork, else Data fork (DF) or MacBinary (MB): e.g. a GIF file or a StuffIt archive will be saved as data fork from DF or MacBinary from MB, an application as MacBinary from both). Lastly, write tar (or bar) file does the reverse of Copy disk archive to file, appending the contents of the tar (or bar) file to the archive, without any conversion.
At any time you may change the preferences settings, to become active at next file (a good moment to do that is during the confirm saves dialog), or resize the window.
Similarly, you may select any enabled command during semimodal dialogs: they look like modal dialogs, except for the window border, but behave differently: you may do anything while they are out, including switching to another task, aborting the current command, moving the dialog and (by holding down the command key, as usual for non-front windows) moving the console window, but you can't hide one of them behind the console (Apple calls them "movable modal dialogs", but suntar's implementation has a different look, without title bars).
In the Preferences menu, the items in the central section are saved when you quit, the other items are "temporary only" and are reset to their initial state when suntar is launched.
Options calls the options box: use the balloon help for options which are not obvious. Anyway, only two options are essential (you should always assign them !): tar version (it tells suntar what to do about multivolume archives) and "text files creator": it's a four characters string which determines the icon of plain text files and the program which is launched when you double click them (EDIT for the Consulair Edit or its "compatible" Edit II, ttxt for TeachText, MACA for MacWrite… you may use Get File Info to discover the string for your favourite editor, Copy the string from the console and Paste it in the options box). A button brings you into a dialog which assigns type and creator to files with a specific extension: e.g. the default setting assigns .jpg files to JPEG View and .Z files to MacCompress, but you may change that and add other types: use Get file info on a file having the icon which you wish and copy the type&creator strings to the options dialog.
Other rarely used options (buffer sizes, background priority, uid, gid...) may be changed only in expert mode (see later).
The ".hqx prefs" submenu is useful if you often download BinHex files. The problem with such files is that they are plain text files. That's good since they may be sent as E-mail and transferred also in the default mode of ftp, without switching to binary mode, but it's bad since they can be, and usually are, edited before arriving at you. So, they may contain extra text or be incomplete: you may disable conversions if suntar fails to extract them and you wish to try again with a specific program. Usually, before the BinHex data there is some text: sometimes it's the only user manual for the application or INIT in the file (and an INIT has no about box and no menus...), other times it's totally useless; so you may want to save that text in a file, or see it on the console, or simply skip it.
English selects the language of messages (Italian or English, the default depends on the national version of your System file).
"Confirm saves" is used during an "Extract and convert" and allows you to extract only some files from an archive: it is a three-state item, clicking on the buttons "Skip all" or "Save all" puts it in a temporary state, you may return to the normal state by choosing it again.
Select Expert mode and suntar will show some new preferences and a new menu: in this "Special" menu "Create log file" opens a file containing everything was printed to the console (and suntar becomes more verbose to make that text more clear). "Extract from sector" is useful when for any reason suntar refuses to extract a file, by extracting the files which follow.
"Find headers" is essentially a "find all files, including lost and deleted ones", "Read tar at sector" (or Extract from sector) recovers them, see balloon help for the other commands. Anyway, since MacTools, the Norton Utilities, the freeware FLUT and other disk utilities will not recognize a tar disk, it's reassuring to know that suntar has some undelete capabilities for disks which crashed or were partly overwritten.
